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_ Systems 



The present invention relates to the transmission 
o£ short data messages in mobile communications systems 
and in particular to the transmission of encrypted short 

data messages. 

Many mobile communications systems support the 
transmission o £ short data messages in addition to voice 
communication, for. for example, carrying various types 
of data such as location information, text messages, 
status (e.g. of the radio-user) messages, telemetry, and 
alarm and warning messages. The Short Data Semc^ 

t fho TFTHA (TErrestrial Trunked RAdio) 
(SDS) mechanism of the TETRA titrie 

„ TS 300 392-2) is one such short 
system (see, e.g., ETSI ETS 30U 

data message protocol. The short Message Servrce (SMS) 
of the GSM (Global System for Mobile communications) 
system (see, e.g. Michel Mouly and Marie-Bernadette 
Pautet The GSM System for Mobile Communications. Cell 
Svs 1992 ISBN 2-9507190-0-7) is another. A similar 
short message service is available on MPT 1327 analogue 
trunked radio systems (see, e.g., MPT 1327 DTI) - 

IC is becoming increasingly desirable to users of 
suc h communications systems to be able to encrypt their 
short data message transmissions. Some communications 
systems such as TETRA and GSM, automatically *-vide 
encryption over the air interface link (using in TETRA 
the standard air interface mechanism,, 
becoming increasingly desirable to provide 
• end-to-end encryption' (i.e. to have the short data 
messages encrypted all the way from the sender to the 
recipient), as, for example, many users, such as public 
safety users, may not wish to rely on the security of 
the existing air interface encryption alone or may not 
trust the security of the fixed infrastructure. 

However, many communications systems may not 



directly support end-to-end encryption of short data 
messages. For example, while the TETRA system provides 
for air-interface encryption of all communications and 
end-to-end encryption of voice communication, the basic 
5 TETRA standard does not directly provide for end-to-end 
encryption of short data messages. 

It is therefore an object of the present invention 
to provide mechanisms for helping radio systems offering 
short data message services, and in particular the TETRA 
10 system, to support end-to-end encryption of short data 
messages . 

The Applicants have recognised in particular that 
where end-to-end encryption of short data messages is to 
be used, there must be some way of indicating to the 

15 recipient that the message includes an encrypted user or 
wanted message, so as to allow the recipient to process 
the message properly. 

According to a first aspect of the present 
invention, there is provided a method of transmitting a 

20 short data message in a TETRA mobile communications 

system, comprising: when the short data message includes 
an encrypted message, including with the message an 
indication of that fact; the method further comprising 
using particular protocol identifier (PID) values as the 

25 encryption indication and forming the short data message 
to comprise the encryption indicating protocol 
identifier, followed by an encrypted part of the short 
data message containing the true protocol identifier for 
the message that is encrypted and the encrypted message. 

3 0 According to a second aspect of the present 

invention, there is provided an apparatus for 
transmitting a short data message in a TETRA mobile 
communications system, the apparatus comprising: means 
for, when the short data message includes an encrypted 

35 message, including with the message an indication of 

that fact comprising means for using particular protocol 
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identifier (PID) values as the encryption indication; 
and means for forming the short data message to comprise 
the encryption indicating protocol identifier, followed 
by an encrypted part of the short data message 
5 containing the true protocol identifier for the message 
that is encrypted and the encrypted message. 

In the present invention, when a short data message 
including an encrypted message is being transmitted, a 
separate indication of that fact (over and above the 
10 mere fact that the message itself is encrypted) is 

included with the short data message. This provides a 
convenient mechanism for indicating to the recipient the 
presence of an encrypted message in the short data 



message . 

The encryption indication precedes the user data in 
the message as this is more convenient where the 
messages may be of variable length (as it avoids the 
need to 'pad out' short messages in such circumstances) 
but otherwise could be placed anywhere in the message, 
although its position should be known to the receiver 
and is preferably therefore predetermined or its 
location previously indicated to the receiver (e.g. in 
an earlier message) . The encryption indication is 
preferably placed towards the start of the message, e.g. 
it prefixes the encrypted short data message. 

The encryption indication is preferably not itself 
encrypted (to allow the recipient to read it) . 

The encryption indication could always be present 
and have two states, indicating respectively "encrypted 
message" and "unencrypted message". Alternatively, the 
indication could only be included with the message when 
it is encrypted or includes an encrypted message, but 
not otherwise (i.e. such that an unencrypted message is 
sent as normal) . 

If the message is not encrypted then the encryption 
indication, if present, would be set to "not encrypted", 
and the remainder of the message arranged as normal . 

If the message is encrypted or contains an 
encrypted message, then the encryption indication would 
be included with it and set to "encrypted". The message 
to be encrypted would be encrypted and sent in an 
encrypted form in the message. 

The message to be sent in an encrypted form can be 
any suitable such message that would normally be sent in 
a short data message but not necessarily always in an 
encrypted form (and for example may typically not be 
end-to-end encrypted in normal use, and/or, for example, 
would not be mandated to be sent in an encrypted form in 
the communications system in question) . It would 
typically be a user message and/or an application 
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message, such as a text message, status message, 
position update, etc., that conveys or can convey 
information (e.g. wanted data) to another user of the 
system, and/or information from an end user or an end 
5 user application, rather than a message that conveys 

system data, such as an OTAR (over- the-air-rekeying) 
parameters message, that allows the system to operate 
but does not convey information proper to an end user. 

The message to be sent in an encrypted form can be 

10 included in the short data message that is sent as 

desired. It could for example be formed by encrypting 
the original user message (e.g. text message, position 
update, GPS message, etc.), and then placing the 
encrypted user message in the "user message" field of 

15 the standard short data message format, with the 

remainder of the message being a 'normal' short data 
message (and including the usual short data message 
headers, etc.) in an unencrypted form, save for the 
presence of the encryption indication. 

20 However, in a particularly preferred embodiment, 

the message to be sent in an encrypted form is first 
arranged in part or all of a normal short data message 
structure including some or all of the usual short data 
message system data headers, fields, etc, (and 

25 preferably at least one such header or field that 

conveys system operation data) , and then the so- formed 
'normal 1 short data message or short data message part 
is encrypted and included with the encryption indication 
in the actual short data message that is transmitted. 

3 0 Most preferably the encrypted normal short data message, 
or short data message part (preferably together with any 
remaining normal short data message headers, etc. that 
would be in a normal short data message, but which are 
not in the encrypted short data message part) , is then 

3 5 packaged into a standard short data message structure, 
i.e. it is effectively placed in an apparently normal 
short data message wrapper, but which structure 



(wrapper) includes the indication that the message it 
contains is an encrypted short data message. Upon 
seeing this indication, the recipient would then decrypt 
the original short data message and thereafter process 
it as a normal short data message. 

Where the message is encrypted, it would typically 
also need to include further encryption information, for 
example in the form of an encryption header, to allow 
the recipient to decrypt the message. This encryption 
information or header preferably follows the encryption 
indication and is preferably in a predetermined or 
prearranged location in the message to allow its easy 
identification by the recipient. Where appropriate, it 
is preferably placed appropriately in the overall short 
data message "wrapper", outside the encrypted short data 
message. It is preferably placed towards the start of 
the message to allow for variable length messages, as 
discussed above. 

TETRA system provides a number of different short 
data message types: short "status" messages, free format 
SDS messages, and so-called type-4 SDS messages. The 
Applicants believe that it will most likely be desirable 
to use type-4 SDS messages for end-to-end encryption, as 
they can contain more user-defined data and therefore a 
longer user message, and as such have a greater capacity 
to carry the user data together with the necessary 
encryption synchronisation information such as the 
encryption synchronisation vector, etc., that may be 
needed to allow the message to be decrypted. 

TETRA type-4 SDS messages are defined in ETSI ETS 
300 392-2, clause 29. Figure 1 illustrates the format 
of one arrangement of a type-4 SDS message. The message 
1 includes a leading "SDS Protocol Identifier" part or 
field 2 which comprises the first 8 bits of the message. 
The protocol identifier enables the SDS application in 
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the radio terminal to route the remaining contents of 
the SDS message to its intended application, and permits 
correct decoding of the message. {Possible applications 
include key management of end-to-end encryption (OTAR - 
5 over- the-air-rekeying) , text messaging, wireless 

datagram protocol WAP, wireless control message protocol 
WCMP, managed TETRA Direct Mode, PIN authentication, and 
GPS position information (see, e.g. ETSI ETS 300-392-2, 
29.4.3.8)) . The user message 3 follows the protocol 

10 identifier 2. 

Type-4 SDS messages can also use an additional 
protocol layer or facility known as the Short Data 
Service Transport Layer (SDS-TL) data transfer service 
(see, e.g., ETSI ETS 300 392-2; 29, 29.4.1, 29.4.2, and 

15 Annex J) . This additional protocol layer enhances the 
Short Data Service protocol and improves message 
transport reliability, etc, by providing protocol 
mechanisms for, for example, end-to-end acknowledgement, 
and store and forward functions. It also ensures that 

20 applications using this service interpret the user data 
in the same way. 

When the SDS-TL protocol is in use, the short data 
message includes additional header information, in the 
form of an SDS-TL header. Figure 2 illustrates such a 

25 message 5. The SDS-TL header 4 is inserted after the 
protocol identifier 2, but before the user message 3. 
In a type-4 SDS message, the first bit of the protocol 
identifier 2 indicates if the SDS-TL protocol is in use 
(see, e.g., ETSI ETS 300 392-2; 29.4.1 and Annex J) and 

30 therefore, for example, if a TL-header is included in 

the message. 

Thus in the application of the present invention to 
a TETRA type-4 SDS message, the encryption indication 
could, for example, follow the protocol identifier and 
35 precede or follow the SDS-TL header, if any. The 

encrypted message would then follow and, have, when 
decrypted, the Standard Type-4 SDS format. 
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Where the TETRA SDS-TL protocol is being used, the 
SDS-TL header may be encrypted if desired. However, the 
Applicants believe that it would generally be preferable 
not to encrypt the TL header, as it may be useful for 
5 the information it contains to still be readable by 

units of the system, e.g. the system infrastructure, or 
another mobile unit, which are not the intended 
recipient of the message (and so cannot decrypt the 
entire message) . For example, the TL header may contain 

10 information which may be used by the system 

infrastructure to determine whether and how long to 
store or forward the message. It would be useful for 
the infrastructure still to be able to read this 
information even if it cannot, and is not intended to, 

15 decipher the entire message. However, if the TL header 
is encrypted, the infrastructure will be unable to 
decode it . 

It may also be preferable for a mobile station to 
be able to read the TL header even if it is unable to 
20 decrypt the rest of the message. This is because the TL 
header may, for example, indicate whether the mobile 
station should report successful or failed reception of 
the message . 

Indeed, in a preferred embodiment of the present 
25 invention, the intended recipient of the message (e.g. 
the recipient mobile station) reports back an error 
message, such as "encoding not supported", if it cannot 
decrypt the message. This could be done in a TETRA 
system using a short report (see, e.g., ETSI ETS 
30 300-392-2, 29.4.3.10) used in the TETRA SDS-SHORT REPORT 

PDU (ETSI ETS 300-392-2; 29.4.2.3), or as a new value 
meaning "unable to decrypt message" in the "Delivery 
Status" parameter (ETSI ETS 300-392-2; 29.4.3.2) used in 
the SDS-REPORT PDU (ETSI ETS 300-392-2, 29.4.2.2). 
35 In a TETRA, SDS-TL protocol, arrangement, whether 

or not the TL header is to be encrypted could, for 
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example, be predetermined, or pre-arranged in use (e.g. 
indicated to the recipient in an earlier message) , or 
indicated by the encryption indication (e.g. by it 
taking a particular value) or within the encryption 
5 header (if any) included in the short data message. 
Although the above described sequences of 
encryption indications, headers and user messages are 
preferred and convenient, in practice the order is 
unimportant so long as the relevant parties know the 

10 order to be used and to expect. 

The encryption indication of the present invention 
is given by using a particular TETRA protocol identifier 
(PID) value or values as the encryption indication. 
This means that the encryption indication is given by 

15 setting a value of an existing part or field of the 

TETRA short data message structure to have a particular 
value or values. (As is shown in the art, the TETRA 
short data message arrangements include headers or 
similar parts or fields that contain "structure data", 

20 i.e. data required for the system to operate but not 

otherwise conveying user information proper, rather than 
proper user information or wanted data, one of which is 
the "protocol identifier". These "structure data" 
elements are normally set to particular values to convey 

25 particular information to allow the system to operate, 

but there are spare, unused values to which these parts, 
headers, fields, etc., can be set to that have not been 
allocated particular meanings. The present invention 
uses previously undefined PID values to have the 

30 meanings "encrypted message" or "unencrypted message", 
etc, and thereby to give the encryption indication.) 

Including the encryption indication within the 
existing short data message structure of the TETRA 
communications system in this way avoids having to add 

3 5 an additional encryption marker and extra marker bits to 
the short data message structure (e.g. as an additional 
bit or bits at the beginning of the message) . This is 



advantageous because the existing short data message 
format for the TETRA communications system would not 
support the addition of a marker in that way, as it does 
not have the capacity for the extra bit or bits of an 
encryption marker. This is, for example, the case with 
TETRA type -4 SDS messages, as the capability of adding 
an extra marker in this way was not included when the 
type-4 SDS service was defined. Thus to add a marker 
onto a standard type-4 SDS message in TETRA is no longer 
so easy to implement, as it would require some 
redefinition of the type-4 SDS service. 

In a TETRA system using Type-4 SDS messages, the 
invention is in one arrangement preferably implemented 
by the encryption indication being two encryption 
indicating protocol identifier values, one having the 
meaning "encrypted SDS message" and the other having the 
meaning "encrypted SDS-TL message", to enable the 
decrypting recipient station to detect the presence of 
the TL header when the SDS-TL protocol is being used. 
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In such an arrangement, when one of these protocol 
identifiers is used, it is preferably followed by the 
encryption header (if any) and then an encrypted version 
of the original message before the encryption was added, 
5 i.e. an encrypted message containing the true protocol 

identifier, SDS-TL header (if any) and the user message. 
In other words, the original message is effectively 
formatted as usual and then encrypted, and then the 
encrypted message mapped onto the usual SDS message 

10 format, but with the so-formed message having a special 

protocol identifier value that identifies it as 
containing an encrypted SDS message. 

As discussed above, while it may generally be 
preferable to keep the TL-header unencrypted, in some 

15 circumstances, it may be desirable to encrypt it. It is 

preferably therefore possible for the recipient to 
determine if the TL-header is encrypted. 

This could be achieved, for example, by having 
three different protocol identifier values, representing 

20 "encrypted SDS message", "encrypted SDS-TL message with 
unencrypted TL header", and "encrypted SDS-TL message 
with encrypted TL header". An infrastructure seeing, 
for example, the protocol identifier "encrypted SDS-TL 
message with unencrypted TL header" would then be able 

25 to look for the TL-header and manage the message in the 
same way as any other SDS-TL message. 

However, the Applicants have recognised that in a 
TETRA system, a protocol identifier having its most 
significant bit set to "0" indicates to the system 

30 infrastructure and mobile stations that they should not 
attempt to read a TL header, whereas as a "1" in the 
most significant bit indicates that a TL header should 
be looked for (see, e.g., ETSI ET3 300-392-2; Annex J). 
Thus as a TL header should not be read in an encrypted 

35 SDS message and an encrypted SDS-TL message with an 

encrypted TL header, a protocol identifier with its most 
significant bit set to "0" can be used to indicate and 
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to allow the system to process correctly such messages. 
As the TL header should be looked for in an encrypted 
SDS-TL message with an unencrypted TL header, a protocol 
identifier with its most significant bit set to "1" can 
5 be used to indicate and to allow the system to process 
correctly such messages. In this way only two protocol 
identifier values are needed to indicate adequately the 
above three possible message states . 

Thus, in a particularly preferred embodiment, two, 

10 and preferably only two, protocol identifier values are 
used to indicate encryption, one having its first (most 
significant) bit set to "0" (zero) which is used for 
encrypted SDS messages and encrypted SDS-TL message with 
an encrypted TL-header, and the other having its first 

15 (most significant) bit set to "1" (one) which is used 

for encrypted SDS-TL messages with an unencrypted 
TL-header . 

Thus any SDS-TL message in which the TL header is 
unencrypted is preferably sent with a protocol 

20 identifier having its most significant bit set to "1", 
so that the recipients know to look for the TL header. 
An SDS-TL message in which the TL-header is encrypted is 
preferably sent with a protocol identifier value having 
a "0" as its most significant bit (as would be an 

25 encrypted SDS message) , thereby effectively instructing 
a recipient not to look for a TL header. In this latter 
case, the fact that the message is in fact an SDS-TL 
message with an encrypted TL-header will become apparent 
when the message is decrypted, because the protocol 

30 identifier of the original message will then be visible. 
The message may then be decoded, managed, acknowledged, 
and disposed of as with any normal unencrypted type -4 
SDS message. 

Although it is preferred to use two or three and 
35 preferably only two protocol identifier values in this 
arrangement as discussed above, more such values could 
be used if it is for example desired to use different 
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protocol identifier values for different types of 
encrypted messages. Thus protocol identifier values 
(other than those already defined for another purpose) 
may be predefined to indicate, for example, the type of 
encrypted message that follows, such as whether it is an 
encrypted text message, an encrypted GPS message, etc. 
These protocol identifier values preferably have their 
most significant bits set to "0" or "1", to indicate the 
presence of an unencrypted TL-header as appropriate, as 
discussed above. 

Thus more generally speaking, the encryption 
indication of the present invention can also be used to 
indicate the type of the encrypted message, if desired, 
e.g. by giving it different values depending on the type 
of encrypted message. 



Short data messages in accordance with the present 
invention can be assembled and transmitted as desired. 
In a particularly preferred embodiment, as discussed 
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above, such transmission comprises the basic user 
message (e.g. GPS message) being formed, and then 
packaged in the relevant short data message (e.g. TETRA 
SDS or SDS-TL) format. The so-formatted message is then 

5 encrypted. 

The need for encryption can be indicated, for 
example, by the user. Alternatively or additionally, it 
could be predetermined that certain messages should be 
encrypted or should be encrypted when certain 

0 predetermined conditions are met. For example, it is 

usually desirable that position information messages in 
particular are encrypted. Additionally or 
alternatively, the destination of the message could be 
used to trigger end-to-end encryption, and/or to at 

5 least select the appropriate encryption key. (However, 
it is preferred that the application determines the use 
of encryption.) Preferably, if an encryption key is not 
available for a particular destination, the message is 
inhibited . 

0 The so-encrypted message is then further packaged 

into the relevant short data message format, but with 
the encryption indication included in it by setting a 
protocol indentifier within the formed short data 
message to have a particular value, together with, if 

5 appropriate, a cryptographic header indicating the 
parameters to be employed for decryption. The 
so-assembled short data message can then be passed for 
transmission over the radio interface. 

Receiving and decrypting an incoming short data 

0 message containing an encrypted message would follow the 
reverse process. 

Thus according to a third aspect of the present 
invention, there is provided a method of transmitting an 
encrypted short data message in a TETRA mobile 

5 communications system that supports short data message 
transmission, the method comprising: 

forming the message to be encrypted; 
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providing a protocol identifier value for the 
message to be encrypted; 

encrypting the message to be encrypted and its 
protocol identifier value; 
5 packaging the encrypted message and encrypted 

protocol identifier value in a TETRA SDS message format; 

providing the so- formed SDS message with a further 
protocol identifier value that identifies the SDS 
message as containing an encrypted message; and 
10 transmitting the so-constructed SDS message. 

According to a fourth aspect of the present 
invention, there is provided an apparatus for 
transmitting an encrypted short data message in a TETRA 
mobile communications system that supports short data 
15 message transmission, the apparatus comprising: 

means for forming the message to be encrypted ,- 

means for providing a protocol identifier value for 
the message to be encrypted; 

means for encrypting the message to be encrypted 
20 and its protocol identifier value; 

means for packaging the encrypted message and 
encrypted protocol identifier value in a TETRA SDS 
message format; 

means for providing the so- formed SDS message with 
25 a further protocol identifier value that identifies the 
SDS message as containing an encrypted message; and 

means for transmitting the so-constructed short 
data message. 

These aspects of the present invention can include 
3 0 any one or more of the preferred features discussed 
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above. For example, in the case of a TETRA system, the 
standard short data message format that the original 
message is packaged into would be either the SDS or 
SDS-TL format (in which case the TL-header could be 
5 encrypted or unencrypted as desired) and the 

encryption- indicating protocol identifier value could be 
prepended to the encrypted original short data message 
when it is repackaged into the appropriate SDS message 
format . 

10 In a preferred embodiment the original short data 

message is marked with a temporary identity tag before 
it is encrypted, which tag is unaltered by the 
encryption process, so that the apparatus can identify 
the encrypted short data message and, for example, send 

15 it to the correct destination. 

According to a fifth aspect of the present 
invention there is provided a short data message for a 
TETRA mobile communications system, comprising: an 
encrypted message, and an indication that the short data 

20 message includes an encrypted message; wherein the 

encryption indication comprises a particular protocol 
identifier (PID) value and the short data message 
comprises the encryption indicating protocol identifier 
followed by an encrypted part of the short data message 

25 containing the true protocol identifier for the message 
that is encrypted and the encrypted message. 

This aspect of the invention can include any one or 
more of the preferred features discussed above. 
The methods in accordance with the present 

30 invention may be implemented at least partially using 
software e.g. computer programs. It will thus be seen 
that when viewed from further aspects the present 
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invention provides computer software specifically 
adapted to carry out the methods hereinabove described 
when installed on data processing means, and a computer 
program element comprising computer software code 
5 portions for performing the methods hereinabove 

described when the program element is run on data 
processing means. The invention also extends to a 
computer software carrier comprising such software which 
when used to operate a radio system or unit comprising a 

10 digital computer causes in conjunction with said 

computer said system or unit to carry out the steps of 
the method of the present invention. Such a computer 
software carrier could be a physical storage medium such 
as a ROM chip, CD ROM or disk, or could be a signal such 

15 as an electronic signal over wires, an optical signal or 
a radio signal such as to a satellite or the like. 

It will further be appreciated that not all steps 
of the method of the invention need be carried out by 
computer software. 

2 0 A number of preferred embodiments of the present 

invention will now be described by way of example only 
and with reference to the accompanying drawings, in 
which : 

Figure 1 shows the structure of a TETRA type -4 SDS 

2 5 message; 

Figure 2 shows the structure of a TETRA type -4 
SDS-TL message; 

Figure 3 illustrates the sending of an encrypted 
type-4 SDS message using a special protocol identifier 

3 0 in accordance with an embodiment of the present 

invention; 

Figure 4 illustrates the sending of an encrypted 
type-4 SDS-TL message using a special protocol 
identifier in accordance with an embodiment of the 
3 5 present invention in which the TL header is 
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encrypted; 

Figure 5 illustrates the sending of an encrypted 
type-4 SDS-TL message using a special protocol 
identifier in accordance with an embodiment of the 
5 present invention in which the TL-header is not 
encrypted; and 

Figure 6 is a schematic diagram showing how an 
encrypted message is handled in a transmitter in 
accordance with an embodiment of the present invention. 

10 Figures 3, 4 and 5 shown embodiments of the present 

invention for transmitting encrypted TETRA type-4 SDS 
messages but use two special "protocol identifier" 
values with the meanings "encrypted SDS message" and 
"encrypted SDS-TL message" to indicate the presence of 

15 an encrypted message. This arrangement does not require 

any addition of an encryption marker to the format of 
normal TETRA SDS messages. 

The SDS messages each comprise a special protocol 
identifier 61, 71, 7 6 that indicates that the SDS 

20 message includes an encrypted user message (in these 
cases that the true protocol identifier and 
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user message are both encrypted) , followed by an 
encryption header 63, 73, which might typically consist 
of an encryption algorithm indicator, a key identifier, 
an initial value (IV) for synchronisation, and, 
optionally, a time stamp and a check sum. This 
encryption header could have a length of, for example, 8 
to 16 octets. The rest of each message follows the 
normal type-4 SDS message structure, but is encrypted. 
Thus they include an encrypted protocol identifier 63, 
74 and the encrypted user message 64, 75. 

In these embodiments, the encryption header 
immediately follows the encrypted SDS message protocol 
identifier and thereafter, the format is the same as for 
unencrypted messages. (Alternatively, the encrypted 
SDS-TL message protocol identifier could be followed by 
the unencrypted 
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TL-header, so that the infrastructure in particular can, 
for example, treat the message like any other SDS-TL 
message . ) 

Figure 3 shows the structure of an SDS message 60 
for sending an encrypted type -4 SDS message in 
accordance with this embodiment. The message includes a 
leading special protocol identifier 61 indicating 
"encrypted SDS message", followed by the encryption 
header 62. There then follows the remaining encrypted 
part 65 of the message, which includes the normal, 
'true' SDS protocol identifier 63 (which is now 
encrypted) and the encrypted user message 64. (Thus it 
can be seen that the parts 63 and 64 are effectively an 
encrypted normal SDS message which is then repackaged 
together with the encryption header 62, into an SDS 
'wrapper 1 having the special "encrypted SDS message" 
protocol identifier 61.) 

Figure 4 shows the structure of an SDS message 70 
for sending an encrypted type-4 SDS-TL message in this 
embodiment with the TL-header encrypted. In that case, 
the special protocol identifier 71 "encrypted SDS 
message" heads the message 70 and is followed by an 
encryption header 62. The remaining part 66 of the 
message is encrypted and follows the same format as a 
normal SDS message, and thus includes the true protocol 
identifier 74 (which is encrypted) , the TL-header 72 
(which is encrypted) and the encrypted user message 75. 

Figure 5 shows the structure of an SDS message 77 
for sending an encrypted type-4 SDS-TL message, which is 
arranged in accordance with this embodiment but in which 
the TL-header is not encrypted. The message 77 includes 
the special protocol identifier 76 indicating "encrypted 
SDS-TL message", which is followed by the unencrypted 
TL-header 78 (which is preferably placed next, so that, 
for example, the infrastructure in particular can treat 
the message like any other SDS-TL message (although in 
practice the actual sequence of headers and indicators 



is unimportant so long as all parties know the sequence 
in advance)), and then the encryption header 73. The 
remaining part 6 7 of the message is then encrypted and 
includes the original, true protocol identifier 74 and 
the user message 75. The use of an unencrypted 
TL-header may be, for example, pre-arranged, or where 
the TL-header can be selectively unencrypted, this fact 
may be indicated appropriately in the encryption marker, 
e.g. by defining a third value for it. 
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Figure 6 shows schematically how encrypted short 
data messages in accordance with the present invention 
may be routed through a TETRA radio unit 100. The unit 
includes a GPS (Global Positioning System) unit 105, 
5 other modules 104, 106 which could be other applications 
such as text messaging or managed Direct Mode which may 
wish to send a received encrypted short data messages 
from time-to-time, a short data service (SDS) 
application unit 102, a cryptographic unit 103, and the 

10 normal TETRA lower protocol layers 101 which prepare the 
message for transmission over the radio interface. 

Figure 6 illustrates the situation where it is 
desired to send a GPS short data message that is 
encrypted. The basic GPS message is sent from the GPS 

15 unit 105 to the SDS application unit 102. The SDS 

application unit packages the message in standard SDS or 
SDS-TL format (as required) . The SDS application unit 
102 also determines whether the message should be 
encrypted, possibly by noting an instruction from the 

20 GPS unit 105 or, for example, by reading some pre-stored 
information requiring messages from the GPS unit to be 
encrypted . 

If the message is to be encrypted, the SDS 
application unit 102 sends the SDS message to the 

25 cryptographic unit 103. The cryptographic unit 103 

encrypts the entire SDS or SDS-TL message and prepends 
the cryptographic header indicating the parameters to be 
employed for decryption. The cryptographic unit 103 
then returns the message to the SDS application unit 

30 102. The SDS application unit 102 then prepends the 
protocol identifier value "encrypted SDS message" or 
"encrypted SDS-TL message", etc., as appropriate, and 
passes the entire message to the lower protocol layers 
101 for transmission over the radio interface. (In an 
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alternative arrangement, the cryptographic unit 103 
could prepend the "encrypted message" indication and 
then pass the message to the SDS application unit 102. 
This may be preferable, as it reduces the risk of 
5 unencrypted material being inadvertently mixed into 
encrypted material by the SDS application unit.) 

If desired, the SDS application unit 102 can mark 
the SDS message with a temporary identity tag before 
passing it to the cryptographic unit 103. The 

10 cryptographic unit should then leave this tag unaltered, 
so that the SDS application unit 102 can identify the 
encrypted SDS and send it to the correct destination 
(for example as requested by the originating GPS 
application unit 105) . 

!5 Receiving and decrypting an incoming SDS message 

would follow the reverse process, except that when the 
unencrypted SDS message is passed from the encryption 
unit 103 to the SDS application unit 102, the SDS 
application unit 102 would be able to read the true 

20 protocol identifier within the message and thereby pass 
the SDS message to its target application (e.g. a text 
displaying application unit, or, in the case of position 
information, a display unit displaying the locations of 
mobile units on a map on a screen) . 

2 5 As can be seen from the above, the present 

invention provides at least in its preferred embodiments 
a way of end-to-end encrypting TETRA SDS messages that 
builds on the existing TETRA SDS mechanism by adding 
end-to-end encryption to the existing SDS type-4 message 

3 0 structure. 
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CLAIMS 



1. A method of transmitting a short data message in a 
TETRA mobile communications system, comprising: when the 
5 short data message includes an encrypted message, 

including with the message an indication of that fact; 
the method further comprising using particular protocol 
identifier (PID) values as the encryption indication; 
and forming the short data message to comprise the 
10 encryption indicating protocol identifier, followed by 
an encrypted part of the short data message containing 
the true protocol identifier for the message that is 
encrypted and the encrypted message. 

15 2 - The method of claim 1, wherein the encryption 
indication is also used to indicate the type of the 
encrypted message. 
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3. The method of claim 1 or 2 , wherein the message to 
be sent in an encrypted form comprises a text message, 
status message, or a position update message. 



4. The method of any one of claims 1 to 3 , wherein the 
short data message which is transmitted is packaged in a 

25 standard short data message structure of the TETRA 
communications system. 

5. The method of any one of claims 1 to 4 , wherein the 
short data message is sent as a type-4 SDS message. 



6. The method of claim 5, wherein the message is sent 
as a type-4 SDS message using SDS-TL and the TL header 
is sent unencrypted. 
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7. The method of any one of claims 1 to 6, wherein the 
transmitted short data message includes encryption 
information to assist the recipient to decrypt the 



( 

message . 

8. The method of claim 7, wherein the encryption 
information follows the encryption indication and is 

5 located outside the encrypted part of the short data 
message . 

9. The method of any one of the preceding claims, 
further comprising the recipient of the message 

10 reporting back an error message if it cannot decrypt the 
message . 

10. The method of claim 9, wherein the error message is 
sent as a short report in the TETRA SDS- SHORT REPORT 

15 PDU, or as a particular value of the Delivery Status 
parameter used in the SDS-REPORT PDU. 

11. The method of any one of claims 1 to 10, wherein 
two encryption indicating protocol identifier values are 

2 0 used, one to indicate an encrypted SDS message, and the 

other to indicate an encrypted SDS message using SDS-TL. 

12. The method of any one of claims 1 to 10, wherein 
two protocol identifier values are used to indicate an 

25 encrypted message, one having its first bit set to "0" 
which is used for encrypted SDS messages and encrypted 
SDS messages using SDS-TL with an encrypted TL-header, 
and the other protocol identifier value having its first 
bit set to "l" and which is used for encrypted SDS 

3 0 messages using SDS-TL with an unencrypted TL-header. 

13. The method of any one of the preceding claims, 
comprising arranging the message to be sent in an 
encrypted form in part or all of a normal short data 

35 message structure for the TETRA communications system 
including some or all of the usual short data message 
system data headers and fields; encrypting the so- formed 
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short data message or short data message part; and 
including the encrypted so- formed short data message or 
short data message part with the encryption indication 
in the short data message that is transmitted. 

14 . A method of transmitting an encrypted short data 
message in a TETRA mobile communications system that 
supports short data message transmission, the method 
comprising : 

forming the message to be encrypted; 

providing a protocol identifier value for the 
message to be encrypted; 

encrypting the message to be encrypted and its 
protocol identifier value; 

packaging the encrypted message and encrypted 
protocol identifier value in a TETRA SDS message format; 

providing the so- formed SDS message with a further 
protocol identifier value that identifies the SDS 
message as containing an encrypted message; and 

transmitting the so-constructed SDS message. 

15. The method of claim 14, wherein the short data 
message format that the original message is packaged 
into is either the SDS message format or the SDS message 
using SDS-TL format, and the encrypt ion- indicating 
protocol identifier value is prepended to the encrypted 
original message and protocol identifier value when they 
are repackaged into the appropriate SDS message format. 

16. The method of claim 13, 14 or 15, further 
comprising marking the original short data message with 
a temporary identity tag before it is encrypted, which 
tag is unaltered by the encryption process, so that the 
encrypted short data message can be identified. 

17. The method of claim 13, 14, 15 or 16, further 
comprising the features of any one of claims 1 to 12 . 
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18. A method of operating a TETRA mobile communications 
system, comprising transmitting or receiving a type-4 
SDS message in accordance with any one of claims 1 to 

5 17 . 

19. An apparatus for transmitting a short data message 
in a TETRA mobile communications system, the apparatus 
comprising : 

10 means for, when the short data message includes an 

encrypted message, including with the message an 
indication of that fact comprising means for using 
particular protocol identifier (PID) values as the 
encryption indication; and 

15 means for forming the short data message to 

comprise the encryption indicating protocol identifier, 
followed by an encrypted part of the short data message 
containing the true protocol identifier for the message 
that is encrypted and the encrypted message. 

20 

20. The apparatus of claim 19, wherein the short data 
message which is transmitted is packaged in a standard 
short data message structure of the TETRA communications 
system. 

25 

21. The apparatus of claims 19 or 20, wherein the short 
data message is sent as a type-4 SDS message. 

22. The apparatus of claim 21, wherein the message is 
30 sent as a type-4 SDS message using SDS-TL and the TL 

header is sent unencrypted. 

23. The apparatus of any one of claims 19 to 23, 
further comprising means for including in the 

35 transmitted short data message encryption information to 
assist the recipient to decrypt the message. 
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24. The apparatus of any one of claims 19 to 23, 
wherein two encryption indicating protocol identifier 
values are used, one to indicate an encrypted SDS 
message, and the other to indicate an encrypted SDS 

5 message using SDS-TL. 

25. The apparatus of any one of claims 19 to 24, 
comprising means for arranging the message to be sent in 
an encrypted form in part or all of a normal short data 

10 message structure for TETRA the communications system 
including some or all of the usual short data message 
system data headers and fields; means for encrypting the 
so-formed short data message or short data message part; 
and means for including the encrypted so -formed short 

15 data message or short data message part with the 

encryption indication in the short data message that is 
transmitted . 

26. An apparatus for transmitting an encrypted short 
20 data message in a TETRA mobile communications system 

that supports short data message transmission, the 
apparatus comprising : 

means for forming the message to be encrypted; 

means for providing a protocol identifier value for 
2 5 the message to be encrypted; 

means for encrypting the message to be encrypted 
and its protocol identifier value; 

means for packaging the encrypted message and 
encrypted protocol identifier value in a TETRA SDS 
30 message format; 

means for providing the so- formed SDS message with 
a further protocol identifier value that identifies the 
SDS message as containing an encrypted message; and 

means for transmitting the so-constructed short 
35 data message. 

27. The apparatus of claim 26, wherein the short data 
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message format that the original message is packaged 
into is either the SDS message format or the SDS message 
using SDS-TL format, and the encrypt ion- indicating 
protocol identifier value is prepended to the encrypted 
5 original message and protocol identifier value when they 
are repackaged into the appropriate SDS message format. 

28. The apparatus of claim 25, 26 or 27, further 
comprising means for marking the original short data 
10 message with a temporary identity tag before it is 
encrypted, which tag is unaltered by the encryption 
process, so that the apparatus can identify the 
encrypted short data message. 

15 29. The apparatus of claim 25, 26, 27 or 28, further 
comprising the features of any one of claims 19 to 24. 

30. An apparatus for use in a TETRA mobile 
communications system, comprising means for transmitting 

2 0 or means for receiving a type-4 SDS message in 
accordance with any one of claims 19 to 29. 

31. A short data message for a TETRA mobile 
communications system, comprising: an encrypted message, 

2 5 and an indication that the short data message includes 

an encrypted message; wherein the encryption indication 
comprises a particular protocol identifier (PID) value 
and the short data message comprises the encryption 
indicating protocol identifier followed by an encrypted 

3 0 part of the short data message containing the true 

protocol identifier for the message that is encrypted 
and the encrypted message. 

32. The short data message of claim 31, wherein the 
35 short data message is a TETRA type-4 SDS message. 



33. The short data message of claim 32, wherein the 
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message is a type-4 SDS message using SDS-TL and the TL 
header is unencrypted. 

34. The short data message of any one of claims 31 to 
33, further comprising encryption information to assist 
the recipient to decrypt the message. 

35. The short data message of claim 34, wherein the 
encryption information follows the encryption indication 
and is located outside the encrypted part of the short 
data message. 

36. A computer program element comprising computer 
software code portions for performing the method of any 
one of claims 1 to 18 when the program element is run on 
data processing means. 

37. A method of transmitting a short data message in a 
mobile communications system substantially as 
hereinbefore described with reference to any one of 
Figures 3, 4, 5 and 6 of the accompanying drawings. 

38. A method of operating a TETRA mobile communications 
system substantially as hereinbefore described with 
reference to any one of Figures 3, 4, 5 and 6 of the 
accompanying drawings . 

39. An apparatus for transmitting a short data message 
in a mobile communications system substantially as 
hereinbefore described with reference to any one of 
Figures 3, 4, 5 and 6 of the accompanying drawings. 

40. An apparatus for use in a TETRA mobile 
communications system substantially as hereinbefore 
described with reference to any one of Figures 3, 4, 5 
and 6 of the accompanying drawings. 
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41. A short data message substantially as hereinbefore 
described with reference to any one of Figures 3, 4 and 
5 of the accompanying drawings. 



